The present invention relates to data networking and more particularly to systems and methods for handling a packet to be forwarded by a network device.
With the continued growth of networks employing Internet Protocol (IP) such as the Internet and enterprise networks, there is a growing requirement for further advances in the performance of packet forwarding devices such as routers and switches. To cope with the growing volume of IP traffic, there is a demand for routers and switches that can receive and forward packets at a very high rate. To simplify network implementation and provide connectivity to large numbers of users and customers, it is desirable to provide routers and switches with very large numbers of ports.
To better meet these requirements, distributed architectures have been developed for network devices. A distributed architecture network device will typically have a very large number of linecards and each of the linecards will have one or more ports for coupling to physical media. Handling of a packet may involve receipt of that packet on an ingress linecard, transfer to an appropriate egress linecard, followed by transmission of the packet to a next-hop network device. The network device as a whole must determine the next-hop destination and appropriate output port for each packet. Various techniques have been developed for distributing the necessary decision-making and control among elements of the network device. The resulting distributed architecture implementations vary in scalability and packet handling speed.
In one approach, not admitted to be prior art, the ingress linecard makes essentially all the forwarding decisions. The ingress linecard performs a lookup in a local forwarding information base (FIB) based on the packet destination address to identify the appropriate egress linecard and next-hop. To facilitate the lookup, the FIB is preferably stored in a content-addressable memory. The ingress linecard also rewrites the packet header to include the appropriate source and destination link layer addresses for transmit to the next-hop and makes any other necessary header changes. Implementing this scheme thus requires that each ingress linecard maintain information about all of the adjacent network nodes for the entire network device. This raises significant scaling issues where there are large numbers of linecards since a very large amount of adjacency information (i.e., information used to select output ports and/or rewrite headers to direct packets to the next hop node) must be maintained on each ingress linecard and any change in the adjacency information must be propagated to all ingress linecards.
In a second architecture, also not admitted to be prior art, the ingress linecard uses the destination address of the packet to pick the correct egress linecard but does not actually rewrite the link layer packet header. Rewrite of the packet header occurs at the egress linecard based on another lookup of the packet's destination. This approach is advantageous from the viewpoint of scalability in that each egress linecard need maintain only the adjacency information for the network nodes to which it connects rather than all the network nodes adjacent to any port of the network device. However, there now need to be two address-based lookups, one on the ingress linecard and one on the egress linecard. Each lookup requires the use of content addressable memory (CAM) and other hardware, increasing hardware cost and complexity. Each address-based lookup also takes time, increasing the overall latency through the router.
In another approach, also not admitted prior art, the ingress linecard performs a destination address-based lookup to identify not only the egress forwarding engine but also a pointer that will be used at the egress linecard to retrieve the adjacency information necessary to rewrite the packet header. The egress linecard then need only use the pointer to retrieve the correct adjacency information for packet rewrite and does not need to do an address-based lookup. This saves on both complexity and processing time. However, there are still concerns about scalability. Even though the ingress linecard does not maintain full adjacency information for all the possible egress linecards, it still must update its stored pointer values to track adjacency changes for the entire network device. Information about adjacent network nodes thus must be maintained and updated centrally for the network device.
Improved distributed forwarding architectures are needed that will be readily scalable to very large numbers of interfaces. It is desirable that these improved distributed forwarding architectures be readily implemented with minimal hardware cost and complexity.